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■ III 

In Units 7 and 8 you learned to write small, standalone 
programs. 

Unit 9 taught you how larger programs can be composed 
of a number of smaller modules. 

■ The theme of this unit is the development of software, 
particularly of large pieces of software. This unit aims to: 
Explain why far more than writing code is involved in progressing 
from an idea for a task to its implementation; 

Demonstrate why activities such as clarifying (analyzing) the 
requirements for the software, designing and testing the software 
are all vital and what are the tasks involves in each one; 

Introduce you to some issues relevant to large-scale 
development, i.e. software development carried out by teams of 
people. 
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Software development in context 

This section aims to: 

Explain why it is important to consider 
software development as a process that 
includes a number of stages; 

■ Describe some aspects of large-scale 
software development as carried out by 
teams of people. 






Software development in context 



Why develop software? 

From what you have learned so far, you might question 
whether anything other than writing code is required in 
order to create a finished software product. 

■ Developing software is a creative process with plenty of 
scope for individual variation, and this can lead to 
different implementations for the same task. 

The production of good software cannot happen without careful 
consideration and proper decisions. 

■ The development of software can be far from 
straightforward. 

Generally, the larger the task, the more complex the process. 

In order to manage such complexity, it is useful to break down 
the development of software into stages. 

Each stage may involve different techniques which the software 
developer can employ in progressing towards their goal of a final 
working product. 
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Software development in context 

Large-scale software development 

Most people are aware that the production of software is 
big business. 

■ The complex and specialist nature of much software 
means that it is often developed by teams of people with 
different specialism. 

■ In this course we concentrate mainly on the activities 
which occur once it has been decided that a software 
application is needed to carry out a task or tasks. 

■ A great deal of investigative work on the potential project 
may already have taken place by this stage. 

■ For example is a computerized system the best way to 
carry out the proposed tasks? If so, does appropriate 
software already exist, in the form of one or more ‘ off the 
shelf packages? 



Software development in coblext 

Large-scale software development 

■ The story doesn’t end once a working software system 
has been delivered. 

Problems which emerge later may need to be fixed. 

Modifications may be required to reflect changes in the client’s 
business. 

■ These activities, which take place after the initial 
‘completion’ of the software, are part of what is known as 
software maintenance . 

Specialist software development companies exist to provide 
clients with some or all of these services, for a fee and to a 
contract. 

Large organizations such as banks may have their own 
departments to carry out both software development and 
maintenance. 
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Software development in context 



Large-scale software development 

When a team of people work on a software development 
project it is usual for members to have different 
responsibilities, with each person specializing in a 
specific stage or aspect of software development. 

Writing code is only one stage in the development process: the 
term programmer ’ is often used to refer to someone whose 
main responsibility this is. 

But for simplicity we will use the term ‘ software developer ’ (or 
developer) to refer to anyone involved in any stage of software 
development. 



A large project can easily involve hundreds of people 
working over a period of years to produce programs 
millions of lines long. 



In these circumstances software development must be a highly 
systematic and professional activity, or there is little chance of 
writing programs that work correctly and meet the customers’ 
requirements. 
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Software development in coblext 

Large-scale software development 

It is important to realize just how big and complex major 
software projects can be. 

■ Different requirements for a software system might 
include: 

Interacting with other complex systems; 

As in a banking system that needs to interact with the BACS 
(Bankers’ Automated Clearing Service) system. 

Supporting thousands of users simultaneously; 

As in a mobile phone network. 

Monitoring and controlling mechanical and electrical devices; 

■ As in an in-car computer. 

Responding to critical conditions that affect safety; 

■ As in railway monitoring system. 

Running continuously for months or years at a time; 

■ As a system for maintaining a power station. 
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Software development in brief 

■ Testing: (and debugging) At this stage the software is 
run and checked. A selection of possible cases are 
tested to ensure that the software behaves according to 
the specification. Errors are corrected. 

■ Documentation: In this activity the thoughts behind the 
design and implementation are written down. These 
explanations of the ideas behind the code are important 
for maintenance. 

■ Maintenance: This is an activity that occurs after the 
release of the product: newly-discovered problems may 
need to be fixed or new/changed requirements may 
need to be implemented by extending or adjusting the 
design. 



What do you require of your software? 

■ This section aims to: 

Explain why it is important to understand as much as 
possible about what is required before starting to 
create software; 

Introduce you to an example, the Overall Continuous 
Assessment Score (OCAS) program, which will be 
used to illustrate aspects of the software development 
process in this and subsequent sections. 
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do you require of your software? 



■ In this section we will cover: 

The two main aspects involved in clarifying the 
system requirements: 

1 . What should the software do? 

■ What does the task involve? 

■ What should the program do? 

2. What does the client want? 

The program specification for the OCAS program. 
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What do you require of your software? 

What should the software do? 

In order to explore some of the issues involved in 
developing a slightly more complex program, we want 
you to think about writing a JavaScript program which 
will work out a student’s OCAS on an Open University 
course. 

■ The first thing to do is to understand the task and work 
out - perhaps on paper - the steps needed to carry it 
out. 

■ If you don’t know how to tackle a task on paper, then you 
have little chance of writing a program to do it. 
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What do you require of your software? 

What does the task involve? 

What is meant by an overall continuous assessment score in Open 
University terminology? 

■ A student’s final grade for an Open University course generally 
depends on both their continuous assessment marks (usually TMAs) 
and their score in the final compulsory assessment component 
(usually an examination). The continuous assessment score is 
known in the Open University as the OCAS. For many courses the 
OCAS is simply an average of the student’s TMA marks. However 
there is one factor that can make the calculation more complicated. 

■ On certain courses, including Ml 50, different TMAs contribute a 
different proportion of the final score. We say that the TMAs are 
differently weighted. The percentage of the final score which each 
TMA contributes is known as a weighting factor and the OCAS is 
known as a weighted average. 
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What do you require of your software? 

What does the task involve? 

■ Our aim is to write a program that will calculate a 
student’s OCAS, allowing for the possibility of elements 
of continuous assessment that are differently weighted. 

■ For simplicity we will refer to the pieces of work that 
contribute to the OCAS as TMAs. 

■ In developing our program we need to consider: 

The student’s individual TMA scores during the year; 

The weighting factor to be applied to each TMA. 
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do you require of your software? 



What does the task involve? 

Before specifying the details of what the program should do, you 
need to gain some understanding of the calculations involved. 

We will start by considering a specific example. Suppose an Ml 50 
student achieves the following TMA scores: 



TMA 


Score 


Weighting 


01 


90 per cent 


11 per cent 


02 


65 per cent 


22 per cent 


03 


78 per cent 


33 per cent 


04 


72 per cent 


34 per cent 



To calculate the weighted average, we need to multiply the score of 
each TMA by its contributed percentage, add them altogether and then 
divide the result by 100 as follows: 

WA = ((90 X 11) + (65 X 22) + (78 x 33) + (72 x 34))/100 
= (990 + 1430 + 2574 + 2448)/100 
= 7442/100 
= 74.42 
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What do you require of your software? 

What should the program do? 

Having gained an understanding of the task involved, what is required may 
appear self-evident. 

The user enters their TMA scores and (if necessary) the weighting factors. 

The computer calculates and displays the corresponding OCAS. 

And you might even be tempted to go immediately to your computer and 
start typing in JavaScript code. 

However, in order to gain a good understanding of the requirements of your 
task, you have to think about questions such as the following. 

Should the program just work for Ml 50 student users? Or should it, for example, 
be usable by a student on a course which has seven TMAs? 

What if all the TMAs have the same weighting? Do we want to use the same 
formula to calculate the overall score? 

What, if anything, should happen if the student enters an invalid data value, for 
example, a negative number for a TMA score? 

What, if anything, should happen if the student enters an unusual set of values: 
zero for each TMA score, for example? 

To what degree of accuracy should the output, i.e. the OCAS, be displayed? 
Should it be a whole number, or a number to one decimal place, or what? 
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What do you require of your software? 



What should the program do? 

There are significant risks in not taking the time to specify fully what 
your intended software is to do. These risks include the following. 

The software may be unnecessarily difficult and time-consuming to 
develop. Lack of clarity at the beginning may mean that you need to 
start again several times. 

For example, you might realize on running your completed program that it 
simply accepts a negative TMA score, and outputs a figure which is 
meaningless. In order to rectify this defect you will have to re-specify your 
task and re-develop your program. 

Your software may not be efficient at achieving the task in hand. That is, 
it may include unnecessary features that the user will never use and 
that make it more difficult for the user to do what he or she really wants. 
For example, you may build into your program the facility to enable the user 
to enter any number of TMA scores, when in fact the software will be used 
only by students on courses with four TMAs. 

The software may be cumbersome to use. 

For example, your program may require the user to input a set of TMA 
weightings even if the TMAs are equally weighted on their course. 
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What do you require of your software? 

2. What does the client want? 

Most of the clients of professional software developers 
rarely have a clear idea of what they want of a system 
and even if they do, there are often possibilities that they 
have not considered. 

■ It is the software developer’s responsibility to clarify the 
requirements with the client and to develop an 
understanding of the client’s situation so that they can 
suggest possibilities for the system. 

If the software developer fails to gain a clear 
understanding of what is expected of the system, then a 
lengthy process of development may result in a system 
that is not acceptable to the client. 
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What do you require of your software? 

2. What does the client want? 

■ The process of gaining an understanding of what is 
required of a system is called requirements analysis . 

This results in a requirements specification , which sets 
out as precisely as possible what is required of the 
software. 

In a professional context it can form the basis for the contract 
between the developers and the client. 

Obviously, it may include information about: 

What the software should do: i.e. what task(s) it should enable the 
user to carry out. 

The details of restrictions on input values, and how the program will 
respond to invalid inputs. 

The details of the user interface to the software. 






What do you require of your software? 



2. What does the client want? 

Another important area to consider during requirements 
analysis is the user interface to the planned software. 

■ An appropriate user interface is essential to enable the 
user to carry out the prescribed tasks, so its specification 
is usually developed at the same time as the plans for 
what the software is to do. 



■ There are a number of relevant questions that could be 
asked in the context of the OCAS program about the 
user interface such as: 






How will the user enter the TMA scores? As responses to a 
series of prompts within dialogue boxes, or through input text 
fields on a form perhaps? 

How will the final OCAS be displayed - in a dialogue box, or via 
an output text box on a form? 
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do you require of your software? 



Clarifying the requirements: 

The potential advantages of gaining a good 
understanding of what is required of the software at the 
start of a project are: 

The software is likely to be quicker and more straightforward to 
develop. 

The software is likely to be efficient at achieving its tasks. 

The software is likely to include all appropriate features. 

The developer and the client are likely to have reached a 
common understanding of what the client wishes the developer 
to achieve. 
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What do you require of your software? 



Program specification for the OCAS program 

■ The OCAS (overall continuous assessment score) 
program will, subject to the assumptions below, calculate 
the user’s OCAS, given their TMA scores. 

■ Here are the assumptions. 

The OCAS is based on at least two pieces of work, and may 
have up to eight. We will refer to these pieces of work as TMAs. 
The TMAs may have different weightings, but the weighting for 
each TMA must be a whole number. 

All summative TMAs must be included, even if the student has 
not submitted them. Each such TMA will be deemed to have 
scored 0. 
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What do you require of your software? 



Program specification for the OCAS program 

The OCAS is calculated as follows. 

If the TMAs are equally weighted 

0CAS _ sum of all TMA score 
number of TMAs 

If the TMAs have different weights 

(TMA score) x (weighting of that TMA) 

Contribution of each TMA is - — 1 

100 

OCAS= sum of contributions, calculated as above 

The user will first be asked, using a dialogue box, for the number of TMAs 
on their course. This input will be checked and if it is not a whole number in 
the range of 2 to 8 the user will repeatedly be asked to re-enter, until the 
input is of the correct form. 

■ The user will then be presented with a series of dialogue boxes, in which 
they are asked to enter their TMA scores, one at a time. If any entry is not a 
whole number from 0 to 100 the user will be repeatedly asked to re-enter, 
until the input is of the correct form. No other checks on the validity of the 
TMA scores will be carried out: for example, a series of zeros will be 
accepted without query. 



What do you require of your software? 



Program specification for the OCAS program 

■ The user will then be asked whether all TMAs are equally weighted. 

■ If they are, the program will calculate the OCAS as a straight 
average. 

■ If not, the user will be presented with a second series of dialogue 
boxes, in which they will be asked to enter the weightings for each 
TMA. If any entry is not a whole number from 1 to 99 the user will be 
repeatedly asked to reenter, until the input is of the correct form. A 
check will then be made that the weightings entered add up to 100. 
If not, the user will be asked to reenter all the weightings. 

■ The program will then calculate the OCAS score, using the 
appropriate formula. 

■ Finally, the program will display the OCAS, to two decimal places, in 
a dialogue box. 

■ It is assumed that the user never presses the Cancel button in 
response to a dialogue box. 
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Designing your software 

■ This section aims to: 

Point out that there can be different ways of 
developing a program to a given specification; 
different developers may follow different paths and 
end up with different, but equally acceptable, 
solutions. 

Provide you with an appreciation of what is involved 
in designing a program. 

Give you the ability to perform small parts of the 
program design process and arrive at a reasonable 
implementation of your design in code. 
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Designing your software 



Why plan your software? 

Once you have thought through what you require of your software, you 
may be tempted to go straight to your computer to begin entering code. 
For very simple tasks this may be a reasonable approach. 

But even though this may or may not have resulted in a working 
program, and it will almost certainly have taken you a relatively long 
time. 



What this unplanned approach is likely to have done is caused you to 
lose sight of the overall program structure, i.e. the logic of your program 
and how the various parts of the code fit together. 

■ Of course for more complex tasks and larger projects this will not work 
fine and hence a planned approach should be used. 

Flumans are generally ill equipped to deal with large and complex 
problems all in one go. 

People naturally try to break a big task into a number of easier subtasks 
which can be solved separately and whose solutions can then be put 
together to provide the solution to the larger problem. 
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Designing your software 



Why plan your software? 

As an example, consider how you might go about shopping for 
several items in a supermarket. You could make your way up and 
down the aisles putting goods into your trolley as you remember (or 
not!) that you need them. The more items you need, the more likely 
it is that you will forget something, perhaps remembering it after you 
have passed the relevant aisle, meaning that you have to backtrack 
to complete your task. You may find, once you get home, that you 
are missing some of the items you intended to buy, i.e. your task 
has not been completed to your satisfaction. 

■ A planned approach on the other hand would involve making a 
shopping list before you set off, setting out the items you need. 

If you are really organized you might group the items according to the 
aisles of the supermarket in which you will find them, thus decomposing 
your shopping into groups of related items (such as fruit and vegetables, 
dairy). 
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Designing your software 

Why plan your software? 

You may recognize this approach from online shopping 
websites, such as online supermarkets. 

The various goods for sale are usually categorized (e.g. dairy). 

Each category may be subdivided into further categories (e.g. butter, 
yoghurt). 

■ The structure of the software reflects the way in which most 
users find it easiest to think about the overall task by 
breaking it down into subtasks. 

Software development is similar to other sizeable tasks in 
the ways people tend to manage it. 

The creation of software of any significant complexity 
benefits from being split into manageable stages which are 
sketched out in advance 
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Designing your software 



Why plan your software? 



There are two related aspects to this approach. 

One is that the structure of the software itself is partitioned 
(divided into parts). 

And the other is that the development process is completed in 
stages. 



■ Our approach does not imply that software development 
should consist of a rigorous (exact and thorough) set of 
steps leading to a finished product: 

Software development cannot be a wholly automatic and 
scientific process, because it always requires a good deal of 
creative input. 



On the other hand it is unlikely to be very productive or 
successful unless it is planned and managed in a fairly 
systematic way. 
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Designing your software 



Beginning design 

A software developer usually manages a project by thinking in terms of 
designing the software, that is creating descriptions of the software either: 

- In words (such as in structured English which was introduced in Unit 8); 

By using diagrams; 

Or using formal notations devised specifically for this purpose. 

The software design process involves a number of different activities and 
techniques. Many of them follow a top-down approach . 

The more general features of the software are considered before the more 
specific ; 

The large before the small. 

■ This enables the developer to concentrate on appropriate levels of detail at 
different stages in the project, without being distracted by relatively smaller 
issues. 

In such an approach the designs start with the specification of the software 
and are progressively refined until a stage of detail is reached from which 
coding is a relatively straightforward task. 
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Designing your software 

Beginning design 

It may be evident that the requirements for a piece of software can be 
naturally divided, or partitioned, into groups of related tasks, each of which 
can be developed independently of the others. 

Having partitioned the requirements, a partition may itself be broken down 
into smaller parts for individual development, and so on. 

Instead of a single large (and probably complex) design for the program, we 
can think in terms of designing a simpler main part of the program which will 
control the flow of execution of the program, calling on a number of 
separately designed modules to carry out specific parts of the program’s 
functionality. 

The initial stage in the process of developing the overall structure and logic 
of the software is sometimes referred to as preliminary design . 

Partitioning the software in a modular way encourages the production and 
the reuse of the developed modules. 
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Designing your software 

Using functions for structuring a program 

JavaScript offers various mechanisms for structuring programs and for 
enabling related subtasks to be implemented as separate code modules. 

A subtask of a program can be implemented as a function. 

Related functions can be grouped together within function libraries, for use by 
more than one program. 

Related data and behavior may be packaged together as an object. 

One role of a function is to enable the program code for a specific task to be 
reused. 

Once the code is written, it can be reused as many times as required by calling 
the function, possibly with different arguments. 

Functions also provide a structuring mechanism. 

- It can make sense to implement a subtask as a function, even if you don’t expect 
that function to be used more than once. 

Using a function in this way removes detailed code from the main part of the 
program, streamlining both the program structure and the development 
process. 
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Designing your software 

Using functions for structuring a program 

We will illustrate these ideas through developing the OCAS program. 

To begin, we set out a design for our program, using structured English. 

The design on which we will base our program is given below. 

get number of TMAs 
get TMA scores 

find out if TMAs are equally weighted 
if they are then 

calculate OCAS as average score 
else 

calculate OCAS as weighted average score 
end if 

display OCAS 

This will form the basic structure for the main part of the program. 

An initial description of the logic of the program, at this sort of abstract level, 
forms what may be called a top-level design for the program. 
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Designing your software 



Using functions for structuring a program 

■ There are many notations by which program designs can be expressed, 
some more formal than others. 

What matters is that they are relatively unambiguous and that they are 
understandable by the developers involved, and by those who might be involved 
with the software in the future. 

There are no rigid rules governing the amount of detail in such a design. 
What is important is that the overall structure of the program should be evident, 
and not obscured by less important features. 

For example, most people would find it acceptable for a top-level design for the 
above program to contain the two steps: 
get TMA weightings 
calculate weighted average score 

in place of the single step: 

calculate OCAS as weighted average score 

But it would be rather more difficult to discern the overall structure if the top-level 
design included, for example, full details of the calculation of the OCAS. 
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Designing your software 

Using functions for structuring a program 

■ There may well be significantly different ways that the 
program can achieve its specification; hence there will 
be more than one acceptable design. For examples: 

We could find out whether the TMAs were weighted before 
getting the scores. 

Our chosen design implies that the OCAS for a course with 
equally weighted TMAs is calculated before reading in the 
weightings for an OCAS based on TMAs with different 
weightings. 

An alternative could be first to get all the possible information 
required from the user and then calculate the OCAS using the 
appropriate formula. 
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Designing your software 

Using functions for structuring a program 

A top-level design where all the necessary information is obtained from the 
user before any calculations take place could be as follows: 

get number of TMAs 
get TMA scores 

find out if TMAs are equally weighted 
if they are not 
get TMA weightings 
end if 

if TMAs are equally weighted 
calculate OCAS (as average of TMAs) 

else 

calculate OCAS (by applying weightings) 
end if 

display OCAS 

One possible disadvantage of this design is that the program will need to 
perform the check to see whether the TMAs are weighted twice. 
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Designing your software 

Using functions for structuring a program 

Just as there can be choices to be made in deciding upon the 
overall structure of the software, so there can be choices to be made 
throughout the process of design. 

From refining the top-level design for the program to refining the 
designs for the modules we introduce. 

■ Having described at a rather abstract level our program design, we 
can now proceed to consider each part of it in more detail, that is, to 
refine the design. 

1 Get number of TMAs 

2. Get TMA scores 

3. Find out if TMAs are equally weighted 

4. Calculate average score 

5. Calculate weighted average score 
6 Display OCAS 
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Designing your software 

Using functions for structuring a program 
1 . Get number of TMAs 

The instruction ‘get number of TMAs’ is a top-level description of the part of 
the program that will retrieve a valid number of TMAs from the user. 

We need to check that the number of TMAs entered by a user is valid (i.e. it is a 
number in the range of 2 to 8). If not, we will have to ask the user to re-enter the 
number until a valid entry is secured. 

We will also need to store the number, so as to know how many TMA scores and 
(possibly) weighting factors are required. 

There will be two other places in our program where we will need to obtain 
numbers from the user and check that they are within a valid range: 

When reading in TMA scores; 

When reading in the weighting factor for each TMA. 

So it would be useful to write a function which would prompt the user for a 
number, check whether it was in a valid range, and if not, continually ask 
the user to re-enter the number until a valid response was received. 
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Designing your software 



Using functions for structuring a program 

We will call this function getValidNumber ( ) . 

We will not consider the coding details of this function at present, but we need to 
provide its specification. 

function getValidNumber f dat aNee ded , st at tO fRange , e ndO f Range l 



/* Function obtains a number in specified range from the user */ 
/* The function takes three argunvents: */ 
/■ da LaNutidud - a string used to specif y what the user should */ 
f* enter */ 
/* s t ar to f Range - a whole number which specifies the */ 
/* lowest valid number in the range */ 
/* endofftange * a whole number which specifies the highest */ 
/* valid number in the r^nge * / 
/* Function returns a valid number in the range */ 
/*••**+++** ***** * 



Now we can refine the first step in our top-level design as follows: 
get number of TMAs using function getvaiidNumber o 
We will need a variable to store the return value, say numberOfTmas. 

It’s useful to make a list of the variables you will need in your program as you go 
along. 
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Designing your software 

Using functions for structuring a program 

2 Get TMA scores 

■ In this step the program will get an appropriate number of valid TMA 
scores from the user, and store them so that they will be available to 
the rest of the program, where they will be needed for calculating the 
OCAS. 

■ How will the program store these values? 

Either by having a number of separate variables, one for each number. 

Or using an array which is the better solution. 

It enables you to store all the TMA scores in a single named object, and 
simplifies the process of carrying out the same operation, such as adding, 
on each stored score. 

■ The task to be performed is slightly more difficult than that of getting 
the number of TMAs, as there could be as many as eight scores. 
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Using functions for structuring a program 

To streamline the main program, we will define a function called 
getTmaScores ( ) , with the following specification. 



function getTmaScores (aNumber ) 

/* Function gets a set of valid TMA scores from the user 
/* The function has a single argument: 

/* aNumber - the number of TMAs on the course 
/* The function returns an array containing the scores 
/* 









The second step in our design can now be refined as: 



get TMA scores using getTmaScores ( ) 



We will need a variable, tmaScores, to reference the array which is 
returned by the function. 

3. Find out if TMAs are equally weighted 

This is a simple task which needs no refinement. 

The response from the user will be stored for subsequent testing. 



zz I «! ■ !■ I ■ lij " 1 1! !il c: \ n\»Z\ 



SJ 



Designing your software 



Using functions for structuring a program 
4 Calculate average score 

■ From the program specification, we know that when TMAs are 
equally weighted, the OCAS is a simple average of the TMA scores, 
i.e. the sum of the TMA scores divided by the number of TMAs. 

■ We have already decided that the TMA scores will be stored in an 
array. 

Finding the average of the values in an array is a fairly straightforward 
task. 

However, calculating the average of a number of values in an array is a 
useful generic task, which we might be able to use in other programs. 

Hence once we have written all the functions for the OCAS program, we 
will create a function library called arrayFunctionLibrary . js and 
move the function to calculate the average of values in an array, as well 
as any other general purpose functions we develop for operating on 
arrays, into that function library. 



■I I ■ i I - I hi mm c: l : 3 - .7 I aeaj “ 



■ 



22 



2 / 23/2010 



Designing your software 

Using functions for structuring a program 

■ Here is a specification for the function, which we will call 

calculateAverage ( ) . 

function calculateAverage (anArray) 



/* Function calculates the average of the values in a */ 
/* non-empty numeric array, correct to two decimal places */ 
/* Function takes a single argument: */ 
/* anArray - the array containing the values */ 
/* Function returns the average of the values in the array */ 



^•k-k-k'k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kic-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k/ 

Note that our comment contains information on the accuracy of the result. 

It may be important for the user to know this information when deciding whether 
the function is appropriate for their purpose. 

In our main program we will need a variable to store the result of the 
calculation, which will in fact be the required OCAS. 

We will call this variable ocas. 





Designing your software 

Using functions for structuring a program 
5 , Calculate weighted average score 

■ This task can be broken down into the two steps: 

get weighting factors 
calculate weighted average 

■ Obtaining a set of valid weighting factors is slightly more complex 
than obtaining the set of TMA scores. 

Not only do we need to check that each weighting factor is within range, 
but we must also check that the weighting factors add up to 100. 

As with the TMA scores, it will be convenient to store these factors in an 
array. 

A function to achieve our purpose would be similar to that for getting the 
TMA scores, with the addition of the extra checking. 

We will call that function getweightingFactors ( ) and following is its 
our specification. 
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Designing your software 



Using functions for structuring a program 

function getWeightingFactors (aNumber) 
/*****************************************************************/ 



/* Function gets a set of valid weighting factors (in the range */ 
/* 1 to 99, with a sum of 100) from the user. */ 
/* The function has a single argument: */ 
/* aNumber - the number of TMAs on the course */ 
/* The function returns an array containing the weighting */ 
/* factors. */ 



/*****************************************************************/ 

■ We will need a variable in our main program to reference the array, 

say weight ingFactors. 



■ Now that we have a set of weighting factors, we can work out the 
OCAS for a course with weighted TMAs. 

This is a relatively complex calculation, involving both the TMA scores 
and their related weighting factors. 

This calculation will be carried out using our final function, 

calculateWeightedAverage () . 
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Using functions for structuring a program 

For the function calculateWeightedAverage ( ) to carry OUt its task: 



- It would need two arguments, the set of TMAs and their corresponding weighting 
factors, and both are numeric arrays. 

- It would return a single numeric value, the weighted average score. 

Here is a function specification. 



function calculateWeightedAverage (valueArray, weightingArray) 
********************************************************** 

/* Function calculates the weighted average of the values 
/* in a numeric array, using the weighting factors provided 
/* in a second array. 

/* Function takes two arguments: 

/* valueArray - the array containing the values 
/* weightingArray - a parallel array containing the 
/* corresponding weighting factors 

/* Function returns the weighted average of the values in 
/* the array, correct to two decimal places. 



*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 



If the branch of the program with a call to this function is executed, the 
return value will be assigned to the variable ocas introduced earlier. 



1 1 ■ n 
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Designing your software 

Using functions for structuring a program 
6 Display OCAS 

The display of the OCAS is a fairly trivial task, which can be 
coded in the main part of the program. 

Putting it all together 

■ We have pursued our top-level design for the main part of 
the program by thinking about how each part of it will be 
achieved. 

For parts such as ‘ find out if TMAs are equally weighted’ and 
‘display OCAS’ we would be able to proceed immediately to 
code. 

In others we have seen that further refinement is necessary, and 
that as part of this it would be appropriate to design and 
implement a number of functions. 





Designing your software 



Putting it all together 

We can refine our top-level design to one which gives more detail about 
how the code will work and clarify our function usage so far, as follows. 

get number of TMAs using function getvalidNumber ( ) 
get TMA scores using function getTmaScores () 
find out if TMAs are equally weighted 
if they are then 

calculate OCAS using function calculateAverage () 
else 

get weighting factors using function getweightingFactors o 
calculate OCAS using function calculatedWeightedAverage () 

end if 

display OCAS 



■ 



This is just one possible design. We could, for example, have combined 

getWeight ingFactors ( ) and calculateWeightedAverage ( ) into a 
single function. 

■i 
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Designing your software 

Putting it all together 

Since we have specified each of the functions that the main program 
code will call, we can at this stage write down the code for the main 
part of the program. 

Alternatively we could first design and code the functions, but seeing in 
detail how it all fits together may assist you in understanding the overall 
structure. 

We will need to declare the global variables that we decided would 
be needed in the foregoing discussion and we will also introduce a 
variable to indicate whether or not the TMAs are equally weighted. 

■ Following is the code for the main part of the program, based on the 
above design and the details of the program specification and the 
function specifications. 

Read through it to see how it ‘maps’ onto the design above. 

The code is almost a line-for-line translation of the design. 
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Putting it all together 

var numberOfTmas; // number of TMAs on the course 

var ocas; // the OCAS (overall continuous assessment score) 

var tmasEquallyWeighted; // whether TMAs are equally weighted 

var tmaScores; //an array holding the TMAs 

var weightingFactors; // array holding weighting factors for TMAs 

// get number of TMAs in the range 2 to 8 

numberOfTmas = 

getValidNumber ( 'Enter number of TMAs on your course', 2, 8); 

// get array of valid TMA scores 
tmaScores = getTmaScores (numberOfTmas) ; 

// find out if TMAs are equally weighted - default value of 'y' 
tmasEquallyWeighted = window. prompt (' Are the TMAs on your course 
equally weighted? Enter y or n', 'y'); //default value of 'y' 

// calculate ocas using appropriate formula 
if (tmasEquallyWeighted == 'y') 

{ 

ocas = calculateAverage (tmaScores) 

> 

else 

{ 

weightingFactors = getWeightingFactors (numberOfTmas) ; 
ocas = calculateWeightedAverage (tmaScores, weightingFactors) 

} ; 

// display final OCAS score 

window. confirm ( 'OCAS (overall continuous assessment score) is: ' 

+ ocas) 

■ ■ 
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Designing your software 

Putting it all together 

As we progress with the OCAS program into the next section it may 
help you to keep in mind the relationships between the main part of 
the program and the functions. 

■ Figure 4.1 is an illustration of where the various parts we have 
discussed so far will be positioned in the program file. 

Figure 4.2 illustrates the current use of functions so far, where the 
arrows indicate ‘uses’. 

For example, the diagram indicates that the main part of the program 
uses the function getTmaScores ( ) . 

As we develop these functions we will introduce others, and add them to 
the figure. 
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Designing your software 




Figure 4.1 Structure of the main OCAS program 
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Designing your software 

Putting it all together 




Figure 4.2 Use of functions in the OCAS program (preliminary version) 
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Detailing your designs; Implementing your software 

In this section we will continue to develop the OCAS 
program by considering the detailed design and then 
coding of each of the functions. 

■ The aims of the section are to: 

Give you an opportunity to practice your JavaScript 
programming skills though a number of practical activities; 

Remind you that throughout the design and coding process there 
are choices to be made, and that there may well be acceptable 
alternatives to ways in which we choose to develop our 
programs; 

Describe documentation that commonly accompanies software 
and its development. 






■I I ■ V I -■ I hi ieBB c: I = 3—1 I mm " 



28 



2/23/2010 



Detailing your designs; Implementing your software 

Developing the functions 

We now turn to each of the functions introduced as part of the 
OCAS program and design and code them. 

We increase the detail of the designs until we reach a description of an 
appropriate algorithm for each part of the code. 

In devising our algorithms we will need to consider where sequence, 
selection and iteration are required to achieve a solution and how the 
related programming constructs (if, for, while) are to be used. 

■ Considering the details of how the software will work, having 
decided upon the overall structure and logic of the software, is 
sometimes referred to as detailed design . 
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Detailing your designs; Implementing your software 

Developing the functions 

Here is the specification for the function getvaiidNumber ( ) . 

function getValidNumber (dataNeeded, startOfRange , endOf Range) 



/* Function obtains a number in a specified range from the user */ 
/* The function takes three arguments: */ 
/* dataNeeded - a string used to specify what the user should * / 
/* enter * / 
/* startOfRange - a whole number which specifies the lowest */ 
/* valid number in the range */ 
/* endOf Range - a whole number which specifies the highest */ 
/* valid number in the range */ 
/* Function returns a valid number in the range * / 



Having displayed an appropriate prompt (using information provided as the 
first argument), the function needs to: 

Check first that the input is a numeric string and then that it is in the range 
specified by the second and third arguments, repeating the cycle as necessary. 
Then return the number. 

A local variable, say number, will be needed to store the input during the execution of 
the function. 



I m I ■ II 
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Detailing your designs; Implementing your software 



Developing the functions 

■ Here is a top-level design for the function getvaiidNumber ( ) . 



while we do not have a valid number 

get input from the user (using the informs 
to formulate a suitable prompt ) 


ition in the arguments 




>test input for validity > 


set isValid to true 
for each character in the input string 
if that character is not numeric 
set isValid to false 
end if 

if isValid is true 

if number is outside required range 
set isValid to false 
end if 
end if 


Y Y 

end while 
return the number 





zz\tm\ ■ !■ 






I hi M 



I c: I :z 1 -■ I I 






Detailing your designs; Implementing your software 



Developing the functions 

Here is our code for 
the function. 



function getvaiidNumber (dataNeeded, startOfRange, endOfRange) 

/* specification would go here */ 

t 

var number; 
var isValid; 

isValid = false; 

while (! isValid) //we don't have a valid input 

{ 

isValid = true; // initialise to true for each iteration 
number = window. prompt ( 'Enter ' + dataNeeded + ' in the range ' 

+ startOfRange + ' to ' + endOfRange, ' ' ) ; 
for (var index = 0; index < number. length; index = index + 1) 

< 

if ( tisNumeric (number .charAt (index) ) ) 

{ 

isValid = false 

> 

}; 

if (isValid) 

t 

number = parseFloat (number) ; 

if ( (number < startOfRange) | | (aNumber > endOfRange) ) 

{ 

isValid = false 

} 

> 

} ; 

return number 

} 
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Detailing your designs; Implementing your software 



Developing the functions 

Here is the specification for the functio n getTMAscores p . 



function getTmaScores (aNumber) 

/* Function gets a set of valid TMA scores from the user 
/* The function has a single argument: 

/* aNumber - the number of TMAs on the course 

/* The function returns an array containing the scores 



/ 

/ 

/ 

/ 

/ 

/ 



■ This function will need to create an array big enough to hold all the TMA 
scores for the course and prompt the user to enter the scores, one at a 
time. 



For each score it will need to check that the score is in the range 0 to 100 
and, if so, store it at the appropriate index of the array. 

We can reuse the getvaiidNumber () function to read in and validate 
each of the TMA scores. 



A for loop will be appropriate here for getting the scores for each of the 
TMAs, one at a time, as we know in advance how many TMAs there are on 
the course. (This information is provided in the function argument.) 



zz I «! ■ !■ I ■ lij " 1 1! !il c: \ n\»Z\ 






Detailing your designs; Implementing your software 

Developing the functions 

Here is a top-level design along with the code for the function 

getTMAscores ( ) . 

create a new array of a suitable size 
for each index of the array 

get a valid TMA score using function getvaiidNumber o 
end for 

return the array 







function getTmaScores (aNumber) 

/* function specification goes here */ 

{ 

var number; // to hold each score as it is input by the user 

var scoreArray; //to reference the array of TMA scores 
scoreArray = new Array (aNumber) ; 

for (var index = 0; index < aNumber; index = index + 1) 

{ 

number = getvaiidNumber (' score for TMA ' 

+ (index + 1) ,0, 100) ; 
scoreArray [index] = number 

>; 

return scoreArray 
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Developing the functions 

Here is the specification of the function caicuiateAverage () , which will 
become part of arrayFunctionLibrary . js of general purpose functions 
operating on arrays. 

function caicuiateAverage (anArray) 



/* Function calculates the average of the values in a non-empty */ 
/* numeric array, correct to two decimal places * / 
/* Function takes a single argument: */ 
/* anArray - the array containing the values */ 
/* Function returns the average of the values in the array */ 



In order to calculate the average we will need to sum (add up) all the values 
in the array. 

Although this is a very simple task, it represents a common pattern in array 
processing, so it would be useful to add this function to our array processing 
library to do this. 

We will call this function sumElements ( ) . 

It will take a single argument, an array, and return a number. 
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Developing the functions 

- Here is our specification for the function sumElements () along 
with our design and the code required. 



function sumElements (anArray) 
/************ ***************** 
/* 

/* 

/* 

/* 

/* 

/* 



Function calculates the sum of the elements in a numeric 
array. 

Function takes a single argument: 
anArray - the array containing the values 
Function returns a number, the sum of the values. 



initialise the sum of the elements to 0 


for each element in the array 


function sumElements (anArray) 


add the element to the sum 


{ 

var sum; // the sum of the values in the array 


end for 


sum =0; 


return the sum 


for (var index =0; index < anArray . length; index = index + 1) 




{ 

sum = sum + anArray [index] 

1 . 




1 ' 

return sum 

> 
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Developing the functions 

Here is our code for the function caicuiateAverage ( ) 



function caicuiateAverage (anArray) 

{ 

var sum; // the sum of the values in the array 

var average; // the average of the values 

sum = sumElements (anArray) ; 

average = sum / anArray. length; 

return lwoDPs ( average) 

} 



At this point it would be useful to update the diagram showing how our OCAS 
program makes use of functions. The updated diagram is shown below. 



main part of program 



caicuiateAverage ( ) 



getTmaScores ( ) 



calculateWeightedAverage ( ) 



getWeightingF actors ( ) 



getValidNumber ( ) sumElements ( ) twoDPs ( ) 



isNumeric ( ) 
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Developing the functions 

Here is the specification of the function getweightingFactors ( ) . 



function getweightingFactors (aNumber) 

/* Function gets a set of valid weighting factors (in the range 
/* 1 to 99, with a sum of 100) from the user 
/* The function has a single argument; 

/* aNumber - the number of TMAs on the course 

/* The function returns an array containing the weighting 

/* factors 



In our design for this function, you will see that: 



We have enclosed the whole process of getting the weighting factors (which 
uses a for loop) inside a while loop. 

This is because we will need to repeat this process an indeterminate number of times 
until the sum of the inputs is 100. 



Also we have initially set this sum to 0. 

In our previous use of while loops for checking the validity of user input we have 
obtained the first ‘real’ input before testing the loop for the first time. 

This approach would have made the design for the current function rather cumbersome, 
as we would have had to repeat the complete for structure before, as well as within, 
the while structure. 
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Developina the functions 

Here is our design for the 
function 

getWeightingFactors () 

along with the code required. 
As usual, yours may be 
slightly different. 


function getWeightingFactors (aNumber) 

/* specification goes here */ 

{ 

var number; //to hold each score as it is input by the user 
var sum; // the sum of the weighting factors 

var weightingArray; 

// to reference the array of weighting factors scores 
weightingArray = new Array (aNumber) ; 
sum =0; 

while (sum != 100) 

{ 

for (var index =0; index < aNumber; index = index + 1) 




{ 

number = getvaiidNumber ( 'weighting for TMA ' 

+ (index +1), 0, 100); 
weightingArrayfindex) = number 


create a new array of a suitable size 
set the sum of the weighting factors to 0 
while the sum is not equal to 100 
for each index of the array 


}; 

sum = sumElements (weightingArray) 

}; 

return weightingArray 

> 


get a valid weighting factor using the function getvaiidNumber o 
end for 

calculate the sum of the weighting factors using 
the function sumElementsO 
end while 
return the array 





in 
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Developing the functions 

■ Here is the specification of the 

calculateWeightedAverage () . 



function calculateWeightedAverage (valueArray, weightingArray) 

/* Function calculates the weighted average of the values in a */ 
/* numeric array, using the weighting factors provided in */ 
/* a second array. */ 
/* Function takes two arguments: */ 
/* valueArray - the array containing the values */ 
/* weightingArray - a parallel array containing the corresponding */ 
/* weighting factors */ 
/* Function returns the weighted average of the values in the */ 
/* array, correct to two decimal places. */ 



function 



- There are many situations where there is a requirement to calculate 
the weighted average of a set of numbers. 

Therefore we should consider this function as a suitable candidate for 
adding to arrayFunctionLibrary . js. 
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Developing the functions 

Here is our design for the function calculateWeightedAverage ( ) 
along with the code required. 

set the sum of the values multiplied by the weighting factors to 0 
for each element in the array containing the values 

multiply the element by the corresponding element in the array 
containing the weighting factors and add it to the sum 
for end 

divide the sum by 100 
return the result to two decimal places 
function calculateWeightedAverage (valueArray, weightingArray) 

// specification goes here 

{ 

var sum; // sum of the values multiplied by the weightings 
var weightedAverage; // the weighted average 



sum =0; 

for (var index =0; index < valueArray . length; index = index + 1) 

{ 

sum = sum + (valueArray! index] * weightingArray [index] ) 

}; 

weightedAverage = sum/100; 
return twoDPs (weightedAverage) 
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Putting it all together 

■ The figure below 
illustrates the overall 
structure of the program. 




functions implemented 
here include isNumericU ^ 
and other string-processing 
functions , 




<HTML> 

<HEAD><TITLE> Final OCA Score/Program</TITLE> 
< SCRIPT SRC="arrayFunctionLibrary .js"> </SCRIPT> 
< SCRIPT SRC="stringUbrary.js"> </SCRIPT> 



<SCRIPT> 

/* program comments to be completed */ 

/* the following functions to be implemented 
here (others may need to be added later) : 
getValidNumber ( ) ; getTmaScores ( ) ; 
getWeightingFactors ( ) * / 

/* main part of the program goes here */ 

</SCRIPT> 

</HEAD> 

<BODY> 

</BODY> 

</HTML> 
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Putting it all together 

■ A complete diagram that shows the use of functions in 
the program is as follows. 



main part of program 

ZZ T~ 











getWeightingFactors ( ) 


calculateWeightedAverage ( ) 












getTmaScores ( ) 


calculateAverage ( ) 


1 





getValidNumber ( ) 



isNumeric ( ) 



sumElements ( ) 



When looking at the OCAS program you should have been aware 
that even for a relatively simple program such as this, we could have 
made a number of different design and coding decisions. 
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Detailing your designs; Implementing your software 

Putting it all together 

The technique of setting out the designs we’ve used so far, 
using structured English of increasing detail, can be very 
valuable in planning a program. 

■ It provides a concrete means of teasing out ideas, 
identifying blind alleys and comparing different possibilities. 

It is a very good way to document how the program works 
and how the code was reached. 

Good documentation of various kinds is essential for the 
program to be maintained in the future. 

The designs may capture patterns that can be reused. 

By clarifying the underlying logic of the solution, a design may 
help us to see how to transfer the same logic to future projects. 
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Documentation 
1 . User documentation 

It is usual to write user documentation to accompany a program. 

This informs the user of the purpose of the program and how to interact with it. 

It does not include any details about how the program is implemented. 

It does not, for instance, mention what variables are used in the code, or what 
kinds of iteration constructs are employed. 

It refers to the operation of the program entirely from the user’s point of view, 
recognizing that they may have no need or desire to know how the program 
works. 

The user documentation may be supplied in a variety of forms depending on 
how the software will be used. 

It may be held in a separate file accompanying the program, or be supplied as a 
paper-based resource, or be presented within the user interface to the program. 

Large software applications often contain built-in user documentation such 
as help facilities, and tutorials to guide the user in the software use. 
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Documentation 

2. Programmer documentation 

■ Programmer documentation is aimed at the needs of those who will 
subsequently maintain the software, or who may want to reuse parts 
of it in other projects. 

■ Function specifications that enable one programmer to use functions 
produced by another programmer in black box programming is one 
form of programmer documentation. 

■ It is sometimes necessary to document the body of the code itself, 
describing what various parts of the code do or how they do it. 

■ You have seen that JavaScript, in common with other languages, 
provides a simple mechanism for you to include comments in your 
code which can be read by the programmer but ignored by the 
compiler or interpreter. This is through use of the // and pairs of /*, 7 
symbols, which we have used often. 

!■■■■ 
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Detailing your designs; Implementing your software 

Documentation 
3. Project documentation 

The two forms of documentation we’ve discussed so far, user and 
programmer, are associated with the implementation of code. 

■ In fact, it is useful to keep records of all stages in the development of 
a piece of software, including: 

The initial specification; 

The information gained in clarifying that specification with the client or 
users; 

Design documentation such as the structured English designs and 
various types of diagram used in this block. 

The overall project documentation, or project log, should incorporate 
descriptions of any part of the development process that might be 
useful for future reference. 
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Detailing your designs; Implementing your software 

Documentation 

■ At an individual level, documentation helps you remember what you 
did at various stages of the development process and why you did it. 

■ On a larger scale, different members of a software development 
team may have different responsibilities, it is possible to find that the 
person designing the code may not be the same person who will 
actually write the code. 

Thus it is vital to record the outcomes (and related decisions) of one 
stage of the project, to feed into the next. 

- Software development companies often have in-house 
documentation standards for their projects. 

These can cover everything from the notations used for recording 
designs, to the style of function specifications and the names used for 
variables. 
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Detailing your designs; Implementing your software 

Summary 

In this section we concentrated on detailed design and coding using 
the OCAS program as an example. 

■ We refined our plans for each part of the program until writing the 
code was fairly straightforward. 

■ The level of detail necessary for easy translation into code varies 
from person to person, and with skill and experience. 

The important aim in design is to arrive at a level where the structure 
and the main constructs to be used are clear. 

■ If you can imagine more than one substantially different way of 
coding a particular design step, then your design does not 
sufficiently clarify the structure of the main coding constructs, and 
you may need to introduce an additional level of design detail. 
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Detailing your designs; Implementing your software 

Summary 

■ If you cannot think how to code a certain step in your design, it is 
likely that you would benefit either from refining the design of that 
step, or from revisiting your previous designs to review the logic of 
your program. 

■ In refining our designs we also identified the need for a couple of 
additional ‘helper’ functions: 

The twoDPs () function from Unit 8; 

And the sumEiements () function, which we designed and wrote. 

■ To conclude, we briefly discussed some types of documentation 
associated with different phases of the software development 
process and the use of a software product. 
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Testing your software 



■ 



■ The section aims to: 

Make you aware of the importance of 
software testing; 

Discuss the different ways in which software 
needs to be tested; 

Introduce you to some testing techniques. 
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Testing your software 



Why test software? 

A program that is accepted by the compiler or interpreter, 
may have no guarantee that it meets its specification in 
terms of functionality, or that it does it correctly. 

Checking both these aspects of software is an important part of 
the development process. 

■ If your program doesn’t run at all or it runs but gives an 
incorrect output, you can be sure that there is an error in 
your program logic or code, and you can proceed to try to 
locate and correct it. 

But if your program appears to behave properly, can you be 
confident that it is error free? Will it do the right thing under 
all circumstances?!! 
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Testing your software 



■ 



Why test software? 

Software developers realized that any program of more 
than a few lines was likely initially to contain mistakes. 

■ So however well you think you have written your 
program, it will need testing before you can feel 
confident that it works as intended. 

■ It is not uncommon for a program to work correctly most 
of the time but to fail in some way with certain inputs. 

■ The process of testing your software, to identify 
differences between what the software is supposed to do 
and what it actually does, is therefore vital. 
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Testing your software 



Why test software? 

In the context of large software projects, testing is a 
major part of the development process. 

■ It is not unusual for the majority of the costs of a 
software development project to be spent on testing- 
related activities. 

■ Recent estimates suggest that up to 75 per cent of 
overall project costs may be allocated in this way. 
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Testing your software 



■ 



Does the program behave correctly? 



■ Usually a program may have different routes, or paths 
(different ways in which the code could be executed, 
depending on the inputs), each of which corresponded to 
a part of the specification. 

So it is essentially to test each route through the code. 

■ Running a program with well-chosen test inputs, to try 
out each different situation outlined in the specification, 
is a reasonable approach. 



■ However it is sensible to first check ‘by eye’ the written 
code - to walk through the code - working out what its 
behavior will be for each test input, and then to verify this 
by actually running the program with each input. 
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Testing your software 



Does the program behave correctly? 

- If there is only a finite number of possible inputs to your program it is 
theoretically possible to thoroughly check your program by running it 
with each of these inputs. 

■ But where there is an infinite number of possible inputs to the 
program, a systematic approach in devising tests is important in 
order that the tests cover all aspects of the program and its logic. 

■ It should be possible to draw up tests from the program specification 
alone, without reference to program code, and to carry them out 
purely by observing whether the executing program conforms to its 
specification in the test cases. This is known as black box testing . 

■ In contrast, white box testing involves looking at the details of the 
program code and devising tests that will exercise each possible 
path through the program. 
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Testing your software 



Testing functions 

Just as a program needs specifying and testing, so does a function. 
There are a number of reasons why we should test a function 
independently as we develop it. 

■ We may want to reuse it in other projects, so we want to be sure that 
it works as a free-standing unit. 

If we simply link the functions into the main part of the program and 
then test the latter, we won’t know where to look for any errors that 
are found; it won’t be easy to tell whether the problem is the result of 
errors in individual functions, or caused by the way they have been 
combined. 

To ease the testing of a function, we can write a very simple 
program to enable us to call the function with different arguments 
and observe its response. 

Such a program is sometimes called a test harness for the function. 





Testing your software 



Extreme value 

■ An extreme value is an exceptional input which is a valid 
input according to the program specification (the 
program is meant to deal with it) but in some respects it 
is a special case, causing the program to deviate from its 
general behavior. 

For example, if the program is required to accept any string that 
the user inputs, then an extreme value might be an empty string. 
You would need to check that the program deals appropriately 
with such inputs. 
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Testing your software 



Boundary values 

■ A boundary value is a value that is at the extreme range 
of the data expected by a piece of code such as a 
function. 

■ Boundary values include the maximum and minimum of 
the expected range of data, plus values that are above 
and just below the maximum and minimum. 

■ Boundary values are often used when testing code 
because if the code works correctly for these special 
values then it is expected that it will work correctly for all 
the values in between. 
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Testing your software 



Using the techniques 

Some errors are rooted in faulty program design or logic 
and some in faulty coding, so it is sensible to test the 
program design as well as the code. 

■ The logic of the program design can be tested by 
walking through it before we even start coding. 

■ Structuring a program using modules has several 
advantages for testing. 

Errors are less likely to occur in the first instance since a 
modular approach focuses on small areas of program logic and, 
if they do occur, they are relatively easily traced and rectified. 

In addition, it is often possible to test individual parts of a 
program as they are developed. 
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Testing your software 



■ 



Using the techniques 

Once we are satisfied that separate modules of the 
program are sound, we still need to test that the program 
behaves appropriately as a whole. 

Such tests are sometimes called integration tests . 

■ It is not uncommon for new errors to be introduced in the 
process of correcting an existing error. 

It is therefore important to rerun the complete test 
cycle once errors have been rectified, or when 
working software is modified. 

This process of repeating tests is known as 

regression testing . 
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Debugging your software 

■ In the previous section we considered what can be involved in 
testing software, a process which aims to discover whether the 
software contains mistakes. 

If you have selected your test cases judiciously (wisely and with care) 
the testing process may also lead you to the cause of the problem. 
However, it is not always easy to locate errors (or bugs) and this is 
where debugging, the process of determining the cause of a program 
problem, comes in. 

■ Our aim in this section is to introduce you to some techniques for 
debugging software which are used in large software development 
projects, as with the testing techniques, and will be useful to you in 
writing your own programs. 

Of course, it’s preferable that you minimize errors when designing and 
coding, and an aid to doing so is an awareness of the kinds of error that 
frequently arise. So we first review some common JavaScript errors. 
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Debugging your software 

Kinds of error 

In Unit 7 you learned that there are two general aspects of a 
programming language that you need to understand when learning 
to program. 

The first is the syntax, the rules of the language you must follow to write 
grammatically correct code statements that the JavaScript interpreter 
will accept. 

The second is the semantics, the meaning of code statements written in 
the language, i.e. the way in which the code will be understood by the 
JavaScript interpreter. 

■ If you make a mistake in either of these aspects, your program is 
unlikely to behave as you intended. 

It may not run at all; 

It may produce incorrect results; 

It may behave in some other abnormal manner. 
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Debugging your software 

Kinds of error 

In compiled languages (which JavaScript is not): 

The first task of the compiler is to check through the whole 
program for syntax errors. 

It is only once these have been eliminated that the compiler 
attempts to translate the source code into machine code, at 
which point it may discover semantic errors. 

■ With an interpreted language such as JavaScript: 

The distinction is not so clear because each program statement 
is checked, translated and executed line by line. 
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Debugging your software 



Kinds of error 

■ The following examples might give you a feel for the 
different types of errors: 

Common syntax errors include forgetting to include both sets of 
quote marks on a string, or having an unequal number of 
opening and closing parentheses. 

Semantic errors include misspelling identifiers, or forgetting to 
initialize them; attempting to access an array index that does not 
exist; writing code to divide by 0. 

The structure (syntax) of the program statements in all these cases 
may be perfectly correct, but when the interpreter tries to use the 
values involved in them, it encounters a problem. 

Logical errors include things such as using the wrong 
comparison operator or defining a while loop which will never 
end. 
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Debugging your software 

Kinds of error 

Some other errors are more difficult to categorize, as one kind of 
error may lead to another, and all three types may be caused by 
typing mistakes. 

So it is not a very useful process to try and assign each error to a 
category. But, for a program to achieve its purpose: 

It must conform to the rules of the programming language being used; 
Operations in the program must be coded so as to operate on 
appropriate values; 

The logic of the program must be correct. 

Careful design is important in achieving the last two points. 

In short pieces of code it is usually possible to locate common errors 
simply by reading through the code. 

But for programs with more complexity, it becomes more difficult to 
do this and hence techniques for debugging software are therefore 
vital. 

■ ■ 
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Debugging your software 

Techniques for debugging software 

1 Tracing variable values 

■ The technique of tracing variable values during the 
execution of a program can be helpful in locating errors 
in programs, particularly errors involving initialization or 
updating of variables, and particularly where the program 
involves repetition. 

■ Tracing through a program can highlight errors and it can 
also confirm that sections of the code are working 
correctly. 






Debugging your software 

Techniques for debugging software 
2. Inserting temporary output 

■ Another way of investigating what is wrong with a 
program is to insert into the program code some 
temporary output statements, which display a trace of 
appropriate values as the program is being executed. 

■ Once you have identified and corrected any problems, 
this code can be removed. 

■ A convenient way of doing this in JavaScript is by using 

window . confirm. 
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Debugging your software 

Techniques for debugging software 

3. Using functions 

■ A common source of errors is misuse of functions, 
particularly when the person using the function is not the 
person who wrote it. 

■ It is important that the user understands the function’s 
behavior: 

What it is and is not supposed to do; 

And under what conditions. 

■ The developer writing the function must provide a clear 
and comprehensive specification, and the developer 
using it must take responsibility for understanding the 
specification and using the function appropriately. 
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Techniques for debugging software 

- Precondition of a function: Conditions to be observed by code 
calling a function, under which a function is guaranteed to behave 
as specified. 



Postcondition of a function: Conditions that are guaranteed to be 
true following the successful execution of a function. 



function sqrt ( x ) 

II Precondition: x >= 0. 

II Postcondition: The square root of x has 
II been written to the standard output. 



□ In tliis example, the precondition 
requires that 

X >= 0 

be tine whenever the function is 
called. 



□ The postcondition always indicates 
what work the function has 
accomplished. In this case, when 
the function returns the square root 
of X has been written. 



■I I ■ I I - I hi tin c: \ I I m* " 



■ 



49 



2 / 23/2010 



Unit Summary 



■ 



In this unit: 

You learned that coding is only one element of a 
systematic process of creating software. 

You were introduced to some activities and 
techniques useful in the larger development process 
and practiced them in your development of the OCAS 
program. 

First we considered requirements analysis, then 
designing the software, and then implementation. 

Having implemented the OCAS program we turned 
our attention to testing and debugging of software. 

You studied some ideas and learned some 
techniques that will be useful to you as an individual 
developing programs. 
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